-
Notifications
You must be signed in to change notification settings - Fork 1
Create/update an issue per feature #7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
956766e
to
0b0a11f
Compare
Co-authored-by: Patrick Brosset <[email protected]>
I think this would work now. @captainbrosset care to review? In particular the issue template is important, and isn't very good yet. |
Co-authored-by: François Daoust <[email protected]>
Seeing that it would "only" create ~300 issues I went ahead and triggered this in https://github.com/web-platform-dx/developer-signals/actions/runs/16290425578/job/45998890724 to shake out additional bugs. Issues are being created now. |
I got the escaping wrong, deleting some code should fix that... |
This should fix < in issue titles
Detecting open issues doesn't reliably work, debugging... Update: fixed |
await writeFile("manifest.json", manifestJson); | ||
console.log('Wrote manifest.json'); | ||
|
||
// TODO: close open issues that were skipped / not updated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this something that should be addressed now or later?
Not sure if it's what you had in mind here, but we should close issues for features that have since graduated to Baseline status, along with a clarifying comment.
On the flip side, if a feature regresses, we should reopen the existing issue to preserve the original upvotes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this something that should be addressed now or later?
I intended to address it later, and basically just close any issues that we didn't put in the manifest. But I wanted to see which issues would be closed in practice before automating it, to see if the rule feels right. One could imagine a different rule for opening new issues vs. closing old issues, with a grace period of sorts.
On the flip side, if a feature regresses, we should reopen the existing issue to preserve the original upvotes.
This is a good point, and would require iterating closed issues as well. Unfortunately I've already made a mess of things with issues that I opened by accident due to a bug, which would lead to multiple issues found for some features. Maybe I could just edit all of those issues to be blank to avoid the problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Making a mess, while working on this script is not a problem. We can always just delete issues and start again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Deleting the issues would be good to avoid having to deal with them in the future. @tidoust do you have admin rights to delete the 35 issues from #324 through #358? They are currently matched by this search.
|
||
For more details on this feature: | ||
|
||
${data.caniuse ? `- [caniuse.com](https://caniuse.com/${data.caniuse})` : ""} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are good resources to point to. I would perhaps add a link to MDN too.
We have some mappings for this too at: https://github.com/web-platform-dx/web-features-explorer/blob/main/additional-data/mdn-docs.json
(soon at https://github.com/web-platform-dx/web-features-mappings/blob/main/mappings/mdn-docs.json)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since there can be multiple MDN links for a feature, sometimes it's a list and each item needs a name of some sort. I see that in https://web-platform-dx.github.io/web-features-explorer/features/individual-transforms/ you went from "Web/CSS/transform-function/translate" to "translate()" and it seems like the code for that is here:
What do you think about publishing the titles as well so I don't need to have a dependency on @ddbeck/mdn-content-inventory
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed. The new separate mappings repo does have the titles already.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, would you be OK with a TODO to add MDN links once web-features-mappings is on NPM?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes.
scripts/update-issues.ts
Outdated
const ids = Array.from(manifest.keys()).sort(); | ||
const manifestJson = JSON.stringify( | ||
Object.fromEntries(ids.map((id) => [id, manifest.get(id)]))); | ||
await writeFile("manifest.json", manifestJson); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
await writeFile("manifest.json", manifestJson); | |
await writeFile("web-features-signals.json", manifestJson); |
The word manifest makes me think of extensions, or PWAs. Sorry, can't help it. What do you think of this more descriptive name?
Also, I see that you're ignoring this file in .gitignore. What do we need it for then? If this is for another use case than just creating/updating issues, then I would move the logic to do this to another script.
Related to this, a file like this would definitely be useful for https://github.com/web-platform-dx/web-features-mappings at some point, so I'm pretty keen on having it, but in this case, I wouldn't ignore it from git.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to publish this file somewhere, that's the main remaining piece before this can be used on caniuse or MDN. Not sure if it should be published on NPM or as a GitHub release, or maybe GitHub pages, but I don't think it should be in the repo itself as the commit history would be completely dominated by that file.
But anyway, I'll rename it to web-features-signals.json now, that works for me.
await writeFile("manifest.json", manifestJson); | ||
console.log('Wrote manifest.json'); | ||
|
||
// TODO: close open issues that were skipped / not updated. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Making a mess, while working on this script is not a problem. We can always just delete issues and start again.
} | ||
} | ||
|
||
// Sort features by earliest release date in any browser, using subsequent shipping |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need to sort the features exactly? I'm not sure I follow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not strictly necessary, but I wanted the issue list to be roughly chronological, with older features being created first, similar to what would happen if this script had been running for years already.
Now that the issues are already seeded I could just delete this. WDYT?
Co-authored-by: Patrick Brosset <[email protected]>
Co-authored-by: Patrick Brosset <[email protected]>
No description provided.